一、核心解决的问题
-
重复操作痛点
- 多包依赖管理
示例场景:管理含数十个包的 Babel 项目时,核心包被 10-20 个其他包依赖,需频繁执行npm link
(手动操作效率极低) - 批量依赖更新
需求:删除所有包的node_modules
并重新安装依赖
痛点:手动逐包执行npm install
耗时,脚本维护成本高(包数量动态变化时需频繁更新脚本) - 单元测试管理
问题:无法选择性执行部分包的测试,需人工校验全部测试结果 - 代码提交管理
反模式:每个包独立 Git 仓库 → 管理灾难
正解:Monorepo 单仓库管理(如 Babel/React 项目) - 版本发布流程
痛点:需逐个包执行npm publish
且手动升级版本号,易出错
- 多包依赖管理
-
版本一致性难题
- 协同升级需求
示例:所有包需统一从 1.0 → 1.1 时,依赖关系需同步更新
风险:手动修改易遗漏依赖项,导致兼容性问题 - 向下兼容成本
对比:类似 Vue3 的长周期发布(需保证向下兼容)
优势:版本一致性可规避大部分兼容问题
- 协同升级需求
二、Lerna 的核心价值
场景类型 | 手动操作风险 | Lerna 解决方案 |
---|---|---|
多包依赖链接 | npm link 操作次数随包数量指数级增长 | 自动处理跨包依赖关系 |
批量命令执行 | 需维护易失效的 Shell 脚本 | lerna run <command> 跨包执行统一命令 |
版本号管理 | 手动修改 package.json 易出错 | lerna version 自动同步版本号 |
依赖更新传播 | 无法自动更新依赖包的版本引用 | 自动修改依赖声明(如 ^1.0.0 → ^1.1.0 ) |
三、适用场景建议
-
推荐使用
- 项目包含 ≥3 个相互关联的 npm 包
- 需要统一管理测试/构建/发布流程
- 存在跨包依赖更新需求
-
可不使用
- 独立单包项目
- 包之间无依赖关系的简单项目
四、典型工作流示例
# 初始化 Monorepo
$ lerna init
# 安装所有依赖(含跨包链接)
$ lerna bootstrap
# 全量运行测试
$ lerna run test
# 交互式版本升级
$ lerna version --conventional-commits
# 批量发布
$ lerna publish from-package